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ABSTRACT 

A class project in a systems progra ming course at the 
University of Michigan sought to produce a system realistic enough to 
warrant production use, the underlying assumption being that tne 
reality of the project would motivate students and provide \:hera with 
valuable experience. Eighteen experienced students in the 
Computerized Registration Involving Student Participation (CRISP) 
project worked with the Michigan Terminal System to produce an 
on-line course registration system for students which would interface 
with those main parts of the current system dealing with room 
scheduling^ transcript production, etc. Interfaces with the current 
Data Systems Center '^ere ordered, student groups with individual 
functions were organi/.ed, and internal and external specifications 
stipulated. The s tudeiit-designed system was sucessfully demonstrated, 
resulting in support 3:rom the cnetral' university administration for 
further development and eventual implementation of the system. The 
conclusion was therefore reached that a class project could produce a 
realistic system, 1) provided that good tools are available, 
particulary a general^pur pose time-sharing system, and 2) that 



continual guidance on the interface 
environment is maintained, (PB) 



with the system's eventual 
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Abstract 

A class project, even for an advanced class in systems pro- 
gramming, is usually simplified to make it possible to achieve 
success. A conflicting goal is to produce a realistic enough 
system to warrant production use, so as to provide the cliass with 
sufficient motivation and the right kind of system experience* 
The problem is compounded v/hen the resulting system is to be a 
component in an on-going information-processing system and must 
be compai:ible with it - with existing documents and procedures, 
with unstated assumptions cibout the data and about the current 
algorithms used to process the data, and with the social and 
institutional traditions that surround it. This paper reports on 
one successful class project of this kind. 



CRISP: An Interactive Student Registration System 
B. A. Gall er^ R. Wagmanr J. Bravatto^ G. Lif t ^ 
G, Kern, V. BerstiS/ and Munn 

Introduction 

In 1971, Arden, Planigan/ and Caller [1] reported on a systems 
programming class based on a group project in some area of systems. 
Clearly, with 15-20 students, over a period of a semester, one 
can undertake a project of some magnitude, but when one considers 
the need for specifying the system to be produced, and the program- 
ming and debugging time involved, there is always pressure to 
simplify the system goals. After all, one of the desired outcomes 
is the successful completion of the project, after facing up to 
the many difficulties involved. 

On the other hand, if the students were to become convinced 
that the exercise is "purely academic," there is a problem in 
motivatio.i and dedication. Students are always involved in a num- 
ber of other activities besides the particular course in which 
the professor is so involved, and if their morale and dedication 
is weakened, the system project will be endangered. The difficulty, 
therefore, is to find a problem that is challenging, educational, 
and feasible, while at the same time realistic, and with enough 
promise of generating a production system to motivate the students 
to put a great deal of time and effort into it. It is also impor- 
tant, of course, to choose very good students with sufficient 



y:)rogramrning background taat they can nlunge directly into the nrob 
1 on with a rninimum of introductory material, and to provide them 
v;ith good tools. In this case, the 18 students (primarily gradu- 
ate students) were all quite good programmers, some v;ith one or 
Tiorc years of experience on campus research projects, and they had 
available to them the facilities of the Michigan Terminal System 
(MTS) , an excellent, general -purpose time-sharing system [2]. 

The Probl em 

During the months preceding the course, the university admini 
tration had been considering the adoption of an alternative to the 
current system of assigning students to cl asses • On a campus in 
which administrative and academic decision-making is highly decen- 
tralized, the system currently in use reflects the historical 
oatuern of growth in v/hich smal 1 changes are superimposed on each 
other in response to demands from many different sources. Changes 
are difficult to implement, and their consequences difficult to 
predict. Although the administrative Data Systems Center (DSC) is 
moving rapidly toward efficient on-line access, this v;as not yet 
being considered as a viable alternative for the student registra- 
tion problem. This, then, was an excellent problem for the class; 
viz, produce an on-line "reservation system'' for students, which 
would interface with the main part of the current system; e.g., 
the part concerned with room scheduling, transcript producing, 
tine schedule printing, etc., and which would be capable of handl i 
the volume presented by 35,000 students taking courses in any or 
all of the Pall, Winter, and Spring-Summer terms, and the Snring 
and Summer half-terms. Moreover, the current lines of students 
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waiting to roqistcr should disappear, and the v/hol e thing r5hoa1d 
cOGt relatively little to run! Finally, while the class-generated 
part of the system would be developed to run under MTS , it would 
have to be planned so that eventually it could be moved to the 
DSC computer • • 

The Interfaces 

One immediate problem was the specification of the interface 
with the current system. Since neither the professor nor any of 
the students who could be expected to enroll would be very familiar 
with the current system at DSC, representatives from DSC were 
solicited to join the class as observers. They would advise on 
the current system's organization and insure compatibility at the 
interface. (One very competent person from DSC subsequently 
enrolled in 'the course, proving invaluable for these interface 
requirements.) One of the authors of this paper joined the class 
as a "participating observer" (no casual observers were allowed, 
because of group morale considerations), and provided very welcome 
and useful insights into the counselling interface that the system 
would have. One additional interface was underrepresented; e.g., 
the Office of the Registrar, where many of the policy decisions 
were being made, and while the difficulties thus introduced have 
now been largely overcome^ it points up a danger in such an under- 
taking. In particular, in areas where the current system is 
ambiguous or unclear, assumptions were made during the course which 
might have been different if the Office of the Registrar had been 
consulted at the time. Fortunately, the final CRISP* system was 
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floxiblo enough to accommodate most of the chanqes they wanted 
to make. 

The charge to the class on the first day is included hc^re as 
Appendix A. The interface to the present system was to be as fol- 
lows: Tapes would be brought from DSC with the current student 
information file, th-^ master catalog of courses, and the specific 
offerings for each term under consideration (up to five at any 
time). These would be used and maintained by CRISP in MTS , and 
subsequently, after students were assigned to courses and sections, 
tapes would be generated for further processing by DSC, 

The CI ass 

The organization of the course was essentially that described 
in [1]. The class was divided into groups, as suggested in Appen- 
dix A/ although on the first day, the students proposed combining 
some of the suggested groups and reassigning some of the resoonsi- i 
bilities. As a result, the following groups were formed: 

Group 1 - Data base initialization programs and batch output 
program specifications. 

Group 2 - Interactive program to accept input from terminal 
operator, check for syntactic val idity, and call on 
group 3 routines to interact vjith data base. Gen- 
eration of user's manual. 

Group 3 - Program to call up student record and appropriate 
course records and process commands as provided 
by group 2. 

Group 5 - Manipulation and maintenance of student and course 
data bases. 

Group 7 - Interrupt handling and post-processing cleanup of 
data bases via batch maintenance program. 

Group 8 - Project management and coordination. 

ERIC 



r.ach ntudont was asked to specify his ov/n choice oC qrouo/ but 
ho v/a3 requested to avoid any group for which ho alrcadv had cxne- 
rienco and expertise. (Here the educational goals of the course 
certainly conflicted with the production goals,) Then the expected 
problems of social organization began to appear, in terms of inter- 
nal group leadership^ a reque'st for transfer of a dissident from 
one group to another group which considered itself large enough 
already, and conununications interfaces between groups. 

The project management function v/as the responsibility of one 
of the groups. They tried several devices to facilitate intergroup 
communication r such as flow analysis, group progress reports, and 
written specifications for interfaces, and some of these were quite 
successful. Others, however, were abandoned as too time-consuming 
for the benefits. The professor attended all classes (and some 
extra-class group meetings), and offered advice, but remained 
largely as a monitor and "friend of the court," as well as a buffer 
to the rest of the university. In some cases, the students ignored 
this friendly advice - and learned from it. An example of this 
v;as the suggestion that in writing code, each group should use 
distinctive symbols suggestive of the group designation. They 
considered this unnecessary, but the subsequent confusion over 
multiply-defined symbols required a fair amount of extra effort. 

Specification ^ 

As seen in Appendix A, the ^vstem needed not only internal 
specification, but external specification as well.* Because of the 
need for compatibility with the current system, and credibility 
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v;ith those familiar with current procedures, it was quickly decided 
that terminal operators using CRISP v;ould extract the information 
they i.eeded for input from existing documents. But the inter- 
active responses to the inputs error diagnostics r and confirmation 
of results^ as well as the necessary on-line file maintenance 
commands and interaction^ had to be specified. Our "participating 
observer" offered to produce a user's manual # which would represent 
the external specif ications ^ and this offer was enthusiastically 
accepted by all. The class wisely counselled the group concerned 
v/ith the interactive part of CRISP to organize that area into 
tcibul'ar constructs to facilitate changes. In fact, this was 
subsequently proven to be very wise, in the ability to add and 
modify many commands and access authorization codes relatively 
easily. It was largely in this area that it proved possible to 
accommodate the wishes of the Office of the Registrar after the 
course was over. 

Imgl ementation 

One lesson the group learned was that the rather enjoyable 
period of arguing over specifications (both external and internal) # 
must come to an end eventual ly^ and hard decisions must replace 
v/ishful general izations* Data structures must be determined, good 
estimates of expected volume of transactions must be obtained, 
and subroutine parameters must be agreed upon; and then a very 
tight rein must be kept on any further revisions. In this case, 
the SDecif ication phase probably lasted two or three weeks too 
long. It was clear to everyone that this was happening, but the 
feeling persisted that the specifications v/ere not yet tight enough; 
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^hat: thoy had not really faced up to CiOrno oi." uhc! roa 1 -v/or I d con^ 
straints that CRISP would havo to live v;ith. A:^ tino ran out, 
.jone design compromises v/t^re finally made, and coding bogan. 

It became apparent that not very much time remained for coding 
and debugging, so a practice was initiated of having each c;roun 

i 

report its progress to the class at each meeting, in terms of 
percentage of expected code already written, and percentage thought 
to be debugged (admittedly difficult to determinel). This neor 
pressure for not delaying the groujj project was very effective, but 
integration of the various components produced by the several 
groups (and only partially debugged in many cases) did nor start 
until the last week of the term. 

Here the debugging and other on-line facilities of MTS proved 
invaluable. During the last week of the course, the system was 
debugged enough to allov; a demonstration two weeks later before a 
number of representatives of the administration, (Of course, only 
those parts of CRISP which could be relied upon were invoked 
during the on-line presentation, but the kind of typical activity 
shov/n in Appendix B was possible even then.) The debugging sessions 
v;ere held a terminal near the batch facility of the Computing 
Center, so large listings and other printouts could be generated 
very easily. One feature of the MTS system which turned out to be 
particularly useful (besides the interactive symbolic debugging 
system and the system on-line editor), was the abil ity to suspend 
activity on one "logical telephone line'* and request access to the 
MTS system via another "logical line," usir^g the same physical ^ 
line. On this second line one could sign on to r^TS under another 
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id'?n tif ica tion number''' and modify or pcrndt filor; to be acc 's:5er] 
by the original task. This kind of flexibility is vjry useial 
v/hcn integrating many components developed in filo^i belonginq to 
different groups working under various identification nuribers. 

Another development in the MTS system, which was anticipated 
during the course^ but which was not actually available until 
four months later ^ was a revision in the MTS file management system 
to authorize a number of terminals to read and/or writ*^ ^ common 
set of files. Such a facility is clearly needed for an on-line 
reservation system^ and with the external specifications already 
available during the course/ the students were able to include 
multiple terminals in the design. 

Subsequent Devel opments 

As a result of the administrative demonstration, a small amount 
of money and some computer time were authorized to support a sub- 
set of the students during the following summer to continue the 
debugging of CRISP. A committee of representatives of the Office 
of the Registrar, the Counselling Office of the major undergraduate 
college^ the CRISP clasS/ DSC, the Scheduling Office, and students 
and faculty from other schools and colleges within the university, 
began to meet throughout the summer to plan a pilot run of CRISP ^ 
using real data. The CRISP group encouraged the use of actual 
student elections, but advocated a ''dry run," so any problems which 
might develop would not jeopardize the credibility of the system 



More recently, under the same number as well* 



wil'.h tho canpui:; comnunity. The oilot run v;a:3 carried out In r>op- 
t'jir.ber, unincj about 12*^ of tho actual advanced classification 
i;tudonl: eloctions for tho Fall term. There were a fev/ smi.ll prob~ 
loMs, but the results were very gratifying. At the time of writing, 
the committee is currently preparing a recommendation on the use 
of CRIS? for the university. 

One interesting question which stil 1 remains is whether to 
continue to use CRISP on the MTS system in conjunction with the 
DSC system, or to convert CRISP to run entirely on the DSC computer. 
In either case, there is the transitional problem or communicating 
v;hat is. known about CRISP and its internal structures to the staff 
of DSC for continued maintenance and development. V7ith all of 
their good intentions, only a few students had the necessary time 
available for adequate documentation. It is clearly an integral 
part of system design, but the magnitude of the project forced 
this aspect to be less than satisfactory. Of course, system docu- 
mentation was eventually generated, but the lesson was learned by 
al 1 concerned. 

Another lesson v/as involved v/ith the ease v/ith which the CRISP 
system could be moved entirely to the DSC computer system. Although 
this had been a goal from the start, and indeed the code had been 
made modular for this purpose, a number of system dependencies 
(i.e., implicit assumptions . about the use of MTS) did creep in. 
For example, since each terminal runs an independent CRISP task on 
an independent copy of MTS (t^hile sharing the actual re^-entrant 
code of MTS), the CRISP system did not itself have to v;orry about 
interacting with more than one terminal. This v/oul d require very 
different treatment in the IBM Operating System at DSC. 
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An intGresting byproduct of the CRISP work was an interactive 
room scheduling and reservation system developed by one of the 
authors for use in the Scheduling Office, When the possibility 
was raised that the use of CRISP might indicate classes that would 
overflow assigned rooms, or that additional sections of a popular 
course would be needed, but academic departments might not be able 
to obtain new classrooms quickly enough, an interactive on-line 
reservation system was suggested. After a simple model was devel- 
oped and implementeu by Professor William Riddle with >.is beginning 
prograiuining class during the summer, more realistic specifications 
were written, and the system was implemented and delivered to the 
Scheduling Office. 

Concl usions 

It is indeed possible to take on a realistic system with an 
advanced class, provided a good set of tools, is available; in parti- 
cular, a flexible general -purpose time-sharing system. Some 
prospect of eventual adoption of the results, if warranted, can 
provide a great deal of motivation. On the other hand, care must 
be taken to have continual guidance on the interface with the 
event.ual environment in which the system will be used. 

The professor must himself be enthusiastic about the project-- 
student criticisms of the course emphasized this point - but he 
must be sure to provide a careful balance between student management 
of the project and his "friendly advice." He must also provide 
enough initial specification to start the design process, but not 
so much as to stifle student initiative. The real challenge is to 
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encourage the students in their natural enthusiasm and creativity, 
teraoered with an appropriate sense of the real world. 
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Proposal for CCS 673 Project CRISP* - B. A, Galler 

1. Conoral description - The problep is to develop a prototype 
(hopefully capable of expansion to a full system for the University 
of iMichigan) for the student registration process, excluding pay- 
Tr(ent of fees, etc. The general operation of the system v^ill be as 
follows: A student will consult a printed Time Schedule as at 
present, including consultation with his counselor, and taking into 
account information on closed sections. He will present a coin- 
pleted course election form to one of several terminal operators, 
who v/il 1 display any elections already confirmed for that student, 
and then key in his elections and request space in his selected 
courses* The system will confirm his elections if possible, and 
the student will receive written confirmation at a later time* 
After confirming a student's current elections, the program will 
request an optional list of preferences for the following term, 
taken from a list of courses to be offered. Students will be 
given an opportunity to indicate desired, but not listed, courses 
as well. Various kinds of queries will be allowed during the pro- 
cess, as well as changes to the Time Schedule information which 
forms the initial data base for the' system. 

2. Input - The initial data base will consist of a selected portion 
(capable of expansion) of the standard Time Schedule, together with 
coded information as to whether certain combinations must be 
elected together (such as lecture and lab), and whether certain 
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courses are cross-listed (so enrollment quotas inust be con^i)ined) , 
etc. In addition, enrollment quotas and "early v/arning'* levels 
should be entered^ if appropriate* (If possible, enrollnent quotas 
should be maintained by major unit, school or college^ by grad/ 
undergrade by class year^ and by concentration. This may be con- 
sidered a special case of a general need for special restrictions 
to be invoked for individual courses , except that it would be 
desirable to be able to get at the quotas dynamically to change 
them.) Provision should be made for a course to be designated as 
having a waiting list once any enrollment quota has been reached. 
(If the' quota is later raised, places will be filled first from 
the v/aiting list according to order of arrival. Thus, if an instruc 
tor \>/ishes to reserve to himself the option of selecting a subset 
of the people who wish to register for his course, he can specify 
a quota of zero, but request a waiting list.) 

3. Terminal Operation ^ The system should support several kinds 
of terminals, including a display device (such as the CDC terminal), 
a teletype or typewriter device, and the touch-tone telephone ARU 
device. Selective responses should be available which are appro- 
priate to the nature of the device. (Input should normally be 
echoed, with additional information added for verification purposes, 
such as course title and/or time at which class meets.) If the 
requested schedule cannot be confirmed, as many reasons should be 
given as possible, so as to minimize the number of return trips 
necessary to obtain an acceptabl e schedul e» (An attempt to register 
for more than one course at the same hour should be flagged with 
a warning, but should not be treated as a "fatal error If a 



request for space in a closed course is made, it should be pos- 
sible to request at the same time {or else be prompted) that the 
student's name be added to the waiting list. Provision should be 
made for periodic listing of closed courses for posting, and for 
interrogation by touch-tone telephone (and spoken response from 
the ARU) by any student as to the status of any course. The report 
of the status should give number enrolled and number of available 
spaces or length of the waiting list. (One might expect a few 
such tel ephones to be connected throughout the day for general 
student use.) Provision should also be made for dropping or adding 
individual courses by s.tudents who have already registered. 

One program (with restricted access) should be designated the 
"master program," and this should be (the only one) authorized to 
change every part of the Time Schedule data, including quotas. 
Courses or sections may be deleted here, v/ith lists of those already 
registered for them available. Other programs will be allowed to 
change quotas for a specific ' department 's courses. Included here 
is the ability to set or change Vearly warning" levels, for flag- 
ging potentially closed courses. Still other programs, for general 
use, should be able to query the status of various parts of the 
data base, such as the number enrolled under any quotas specified, 
the length of the waiting list^ whether a particular section is 
closed, how many students have enrolled so far, how many today, a 
particular student's elections already confirmed, etc. 

4. Output - The system should supply on demand a printed report 
of the current status of all (or a subset of) course enrollments, 
a closed-course list (including a separate list of changes - 



additions and delations - since the last closed-course list :ippearod) 
a list Ojl students enrolled in each course (with an additional 
list of names on the waiting list), and a schedule for each student 
.showing his confirmed elections, 

5. Data Base Management - The new file sharing features of MTS 
should be available in time for this course. Provision v;ill have 
to be made for back-up and recovery in case of system crashes, as 
v;el 1 as temporary lock-out on elections until they are confirmed 
or rejected (including delays due to prompting for waiting-list 



Documentation - In addition to documentation of the internal 
organization of all components of the system, there should be a 
User's Guide which would include instructions for preparation of 
input data, instructions for operating a terminal , instructions 
to a student as to how to specify his desired elections and query 
for closed courses or the status of a particular course, and a 
list of possible diagnostics and the causes for their occurrence. 

7 . Suggested Functional groups for class implementation of CRISP - 



action) « 



Function 



Approximate 
Size of Group 



1. 



Input Specifications , Initial ization 
of data base. Specification of Storage Structures 



3 



2. Command Language Specifications and Interpreter 



3 



3. 



Terminal support and Query Programs 



2 



4. 



Special Course Restriction Routines, System Macros 



5. 



Data base management, protection, interlocks 



3 



6. 



Generation of output 



If) 



I^estart, recovery, back-up 



2 



SyGtcm integration, maintonanco of system v/orkbook, 
project coordination, code efficiency 



2 



User's guide and test environment, interaction 
v;ith Registrar's Office 



Total 



21 



Specific Responsibil ities of Functional Groups - 

8 . 1 Input Specifications, Initialization of Data Base, etc, - 
This group will obtain input tape from Administrative Systems, 
modify it as necessary to include quota information, early 
warning lev^";s, relationships between lectures and labs, etc., 
and indications of courses which require special "restriction 
subroutines." This group is also responsible for specification 
of the storage structures to be used and for routines for 
bringing this data into appropriate files. A similiar respon- 
sibility exists for the list of courses for the following 
term{s) for preference tabulation. Routines should be provided 
for updating these tapes as necessary after acquisition from 
Administrative Systems . 

8. 2 Command Language Specifications and Interpreter - 
This group specifies the various commands for interrogating 
the data base, entering student election's, and modifying the 
data base. They will provide appropriate prompting routines, 
and an interpreter which will analyze commands and issue calls 
on various routines as necessary. (The called routines will 
be generated by other groups.) 
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8,3 Terminal Support and Query Programs' - This group will 
determine the appropriate forms in which input/output is to 
occur on the various devices to be used, (Some prompting 
or display might be appropriate for one type of device and 
not another.) This group will also implement the routines 
which search the data base and which modify it. (These 
routines wil 1 cal 1 upon primitive routines provided by group 
8.5.) 

8 • 4 Special Course Restriction Routines^ System Macros - 
This group will generate the special course "restriction sub- 
routines*' needed to enforce particular rules. (This is not 
the checking of prerequisites^ which is not intended here.) 
These subroutines will be invoked during the attempt to con- 
firm a student's elections. This group will also maintain 
the file of macros developed by the course activity. 

8.5 Data Base Management y Protection ^ Interlocks - This group 
v/ill provide the primitive routines used by the query and 
modification programs in searching and changing the data base. 
This group will provide appropriate checks for authorization, 
interl ocking, obtaining and freeing space, etc. 

8.6 Generation of Output - This group will provide routines 
for printed reporting of confirmed student elections, class 
lists, waiting lists, deleted course lists, closed course lists, 
etc. These routines will be invoked via the Command Language 
Interpreter. They wi^l also generate a final status tape to 
return to Administra^f^ive Systems for later processing. 



8.V Restart, Recovery, Pack-Up - This group wiM advise the 
ochers on appropriate code to be used to facilitate rocovGry 
and restart after system failures^ Routines will be provided 
for back-up as necessary. Restart and recovery procedures 
will be specified and in^pl emented. 

8 • 8 System Integration, Maintenance of System Workbook, Pro- 
ject Coordination, Code Efficiency - This group v/ill assume 
coordination responsibil ity ^ setting goals and monitoring them. 
Approval of changes to project specifications resides here, 
as well as monitoring individual groups* documentation and code 
efficiency. The system workbook will be maintained in one or 
raore files by this group, and they will implement a skeleton 
system for use d'\ring system integration. 

8.9 User's Guide, Test Environment, Interaction with Registrar's 
Office - This group will interact with and represent the user 
community for this system. They will lobby for whatever improve- 
ments are deemed desirable/ and they v;il 1 be aware of the user 
interface. They v;ill generate a User's Guide suitable to 
instruct terminal operators and students to interact with the 
system and to interpret the output to be produced. They will 
create a test environment for the system. 

V 

MODIFICATION 1 - Conditional Enrollment Threshold (CET) 

In the CRISP proposal, provision is made for "early v/arning'* 
levels, which would initiate messages to departments when enroll- 
ment reached preset levels. We now replace the "early warning" 
coucept with the Conditional Enrollment Threshold (CET), which will 
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bG set (and dynamically changed) by departments, just as quotas are 
set and changed. 

When the enrollment in a section has reached the GET level, 
requests for enrollment by students will be rejected unless a parti 
cular "counselor priority" indication is entered for that course. 
The operator will enter it only when a signed message is received 
from a counselor. If the enrollment in a section has in fact 
reached the section quota, ''counselor priority" requests will be 
queued in the order of arrival at the head of the waiting list, so 
that such people will be the first admitted to a course if the 
quota- is subsequently raised^ 

The GET is intended to reserve places in sections for those 
whom counselors are willing to indicate as having special problems 
and who need special priority. A department may set the GET to 
zero, requiring special permission for everyone, or they may set 
the GET equal to the quota for a section (the default case), in ^ 
which case no counselor priority would be needed for anyone. The 
response to an interrogation about enrollment in a course should 
indicate whether the GET has been reached. If there is a waiting 
list, the length of the GET portion and the length of the non-GET 
portion would be reported, also. 

MSpiFICATION 2 - Piecewise Registration 

It is quite possible that registration procedures will be 
spread over several weeks, and that different groups of students 
v;il 1 be registered in different time periods, such as by alpha- 
betical groupings. In this case, it would be desirable to increase 
the enrollment quotas whenever a new time period began, without 
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..oc..se>rily admitting these cn the waitin, Ust fro™ the proce..n, 

oeriod.. The program which allows departments to change 
Cuotas, therefore, should allow for modification of quotas without 
the automatic entry into the course of people from the v Uting 



1 ist. 



Appendix B - CRISP Output 



YOU AUt- now CONVERSING WITH CRISP 
^Ici 2iU52 73 192 

2IU-52-7319-2 WIRE BARBARA 
iO;0U.lG 01-29-73 
•^ELECTIONS FOR FALL * 



77 L 



•••rELCCTIONS FOR FALL * 
1353 CCS Ii73 3 001 
2 355 C C S 673 3 001 , 
TOTAL CREDIT HOURS FALL 6 
*id 123145678Q9 

** UO RECORD: l23-'+5-5789-9 
*insert 123ti567899 name=wilson pIckett fence unit=-l year»58 



INSERT 123-U5-6789-9 WILSON PICKETT FENCE 
?ok 

DO.ME 10:05. t;3 
*st 353 673 001 



68 L 



FALL 353 C C S 
SEC LIMITS 
001 MAX 21 CET 10 
*Id 123t|567899 



6 73 SYSTEMS PROGRAMMING 
ENROLLED AVAILABLE 
TOT 1 REG 9 PRI 11 



WAITING 
REG 0 PRI 0 



123-45-6789-9 WILSON PICKETT FENCE 
10:07.31 01-29-73 
*N0 ELECTIONS FOR FALL * 
*ad 353 673 3 001 
3 001 
3 001 



68 L 



*ad klS 555 
*ad ti28 684 
*hr 9 
ECHO: 

1 ADD 

2 ADD 

3 ADD 



353 C C S 673 3 001 

428 MATH 555 ■ 3 001 

428 MATH 684 3 001 

TOTAL CREDIT HOURS FALL 9 
*update 



FALL ELECTIONS CONFIRMED FOR 9 HOURS CREOtT 10:08.51 

★ELECTIONS FOR FALL * 

1 353 C C S 575 3 001 

2 428 MATH 555 3 001 

3 428 MATH 684 3 001 
TOTAL CREDIT HOURS FALL 9 



D:0 



A:3 



W:0 



Nl: 1 



N2:0 K28D 



KEEP THIS/ IT'S NOT LITTER 



*icl 21iv52 75192 



21U-52-7519-2 WIRE BARBARA 77 L 

10:09.39 01-29-73 

, SELECTIONS FOR FALL * 
-drop 353 473 3 001 

*ad h2S 555 3 002 

*hr 3 

ECHO: 

1 DROP 353 C C S 473 3 001 

2 ADD 428 MATH 555 3 002 
TOTAL CREDIT HOURS FALL 3 

*up 

FALL ELECTIONS CONFIRMED FOR 6 HOURS CREDIT 10:11.02 
** CHECK HOURS! ENTERED: 3 CONFIRMED: 6 

♦ELECTIONS FOR FALL * 

1 353 C C S 573 3 001 

2 428 MATH 555 3 002 
TOTAL CREDIT HOURS FALL 6 

D:l A: 4 W:0 Nl:l N2:l K28D 

GUARD THIS -WITH YOUR LIFE (IT IS YOUR LIFE) 
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